Method for transmitting/receiving encryption information in a mobile broadcast system, and system therefor

ABSTRACT

A system and method for transmitting/receiving encryption information in a mobile broadcast system supporting broadcast service (BCAST) are provided. In the mobile broadcast system, a BCAST Subscription Management (BSM) manages subscriber information of a terminal, and transmits to a BCAST Service Distribution/Adaptation (BSD/A) a first delivery message including a Registration Key Material (RKM) provided for registration of the broadcast service of the terminal and including at least one service or content&#39;s identifier. The BSD/A transmits to the BSM a first delivery confirmation message including information indicating success/fail in receipt of the first delivery message, and transmits the RKM to the terminal.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit under 35 U.S.C. § 119(a) of KoreanPatent application Serial No. 2005-107760 filed in the KoreanIntellectual Property Office on Nov. 10, 2005, the entire disclosure ofwhich is hereby incorporated by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to an encryption method andapparatus in a mobile broadcast system. More particularly, the presentinvention relates to a method for transmitting/receiving encryptioninformation for service/content protection in a mobile broadcast system,and a system therefor.

2. Description of the Related Art

In general, Broadcast Service (BCAST) refers to a technology in which aserver, managing a broadcast service, broadcasts encrypted service andmultiple terminals receive the encrypted broadcast service. Each of theterminals decrypts the encrypted service provided from the server usingits own encryption key, thereby allowing the user to enjoy thecorresponding service.

The BCAST service may be a charged service. To meet the demand forcopyright protection technology for preventing illegal copying anddistribution of the service, 3rd Generation Partnership Project (3GPP)or Open Mobile Alliance (OMA), which is a standards group, hasintroduced a Digital Rights Management (DRM) technology based onflexibility and facility for Right Object (RO) of the user. However, themobile broadcast system gives no definition of an encryption method forservice protection between entities and of interfaces between theentities, so there is a need to define the encryption method.

Accordingly, there is a need for an improved apparatus and method fortransmitting/receiving encryption information in a mobile broadcastsystem.

SUMMARY OF THE INVENTION

Exemplary embodiments of the present invention address at least theabove problems and/or disadvantages and provide at least the advantagesdescribed below. Accordingly, an aspect of the present invention is toprovide a method for transmitting/receiving encryption informationbetween entities in a mobile broadcast system, and a system therefor.

According to one exemplary aspect of the present invention, there isprovided a method for transmitting/receiving encryption information in amobile broadcast system supporting broadcast service (BCAST), whereinthe mobile broadcast system includes a BCAST Subscription Management(BSM) for managing subscriber information of a terminal and generatingan encryption key with which the terminal decrypts at least oneencrypted service or content, and a BCAST ServiceDistribution/Adaptation (BSD/A) for transmitting the encryption key. Themethod comprises transmitting by the BSD/A to the BSM a first requestmessage including the at least one service or content's identifier andrequesting, delivery of a Registration Key Material (RKM) forregistration of the broadcast service of the terminal and upon receivingthe first request message, the BSM transmitting a first request responsemessage including the RKM to the BSD/A.

In an exemplary embodiment, the method further comprises transmitting bythe BSD/A to the BSM a second request message including the at least oneservice or content's identifier and requesting delivery of a Long-TermKey Message (LKM) provided to the terminal during subscription of abroadcast service and upon receiving the second request message, the BSMtransmitting a second request response message including the LKM to theBSD/A.

In an exemplary embodiment, the method further comprises transmitting bythe BSD/A to the BSM a third request message including the at least oneservice or content's identifier and requesting delivery of a Short-TermKey Message (SKM) including a Traffic Encryption Key (TEK) used fordecryption of the particular broadcast service by the terminal and uponreceiving the third request message, the BSM transmitting a thirdrequest response message including the SKM to the BSD/A.

According to another exemplary aspect of the present invention, there isprovided a method for transmitting/receiving encryption information in amobile broadcast system supporting broadcast service (BCAST), whereinthe mobile broadcast system includes a BCAST Subscription Management(BSM) for managing subscriber information of a terminal and generatingan encryption key with which the terminal decrypts at least oneencrypted service or content, and a BCAST ServiceDistribution/Adaptation (BSD/A) for transmitting the encryption key. Themethod comprises transmitting by the BSM to the BSD/A a first deliverymessage including the at least one service or content's identifier andincluding a Registration Key Material (RKM) for registration of thebroadcast service of the terminal and the BSD/A transmitting to the BSMa first delivery confirm message including information indicatingsuccess/fail in receipt of the first delivery message.

In an exemplary embodiment, the method further includes transmitting bythe BSM to the BSD/A a second delivery message including the at leastone service or content's identifier and including a Long-Term KeyMessage (LKM) provided to the terminal during subscription of abroadcast service and the BSD/A transmitting to the BSM a seconddelivery confirm message including information indicating success/failin receipt of the second delivery message.

In an exemplary embodiment, the method further comprises transmitting bythe BSM to the BSD/A a third delivery message including the at least oneservice or content's identifier and including a Short-Term Key Message(SKM) including a Traffic Encryption Key (TEK) used for decryption ofthe broadcast service by the terminal and the BSD/A transmitting to theBSM a third delivery confirm message including information indicatingsuccess/fail in receipt of the third delivery message.

According to further another exemplary aspect of the present invention,there is provided a mobile broadcast system supporting broadcast service(BCAST). An exemplary mobile broadcast system includes a BCASTSubscription Management (BSM) for managing subscriber information of aterminal, and for transmitting to a BCAST ServiceDistribution/Adaptation (BSD/A) a first delivery message including aRegistration Key Material (RKM) provided for registration of thebroadcast service of the terminal and including at least one service orcontent's identifier; and the BSD/A for transmitting to the BSM a firstdelivery confirm message including information indicating success/failin receipt of the first delivery message, and transmitting the RKM tothe terminal.

In an exemplary embodiment, the BSM transmits to the BSD/A a seconddelivery message including a Long-Term Key Message (LKM) provided to theterminal during subscription of a particular broadcast service and alsoincluding at least one service or content's identifier; and the BSD/Atransmits to the BSM a second delivery confirm message includinginformation indicating success/fail in receipt of the second deliverymessage, and transmits the LKM to the terminal.

In an exemplary embodiment, the BSM transmits to the BSD/A a thirddelivery message including a Short-Term Key Message (SKM) including aTraffic Encryption Key (TEK) used for decryption of the broadcastservice by the terminal and also including at least one service orcontent's identifier; and the BSD/A transmits to the BSM a thirddelivery confirm message including information indicating success/failin receipt of the third delivery message, and transmits the SKM to theterminal.

According to yet another exemplary aspect of the present invention,there is provided a mobile broadcast system supporting broadcast service(BCAST). An exemplary mobile broadcast system includes a BCAST ServiceDistribution/Adaptation (BSD/A) for transmitting to a BCAST SubscriptionManagement (BSM) a first request message requesting delivery of aRegistration Key Material (RKM) for registration of the broadcastservice of a terminal and including at least one service or content'sidentifier, and upon receiving the RKM from the BSM, transmitting theRKM to the terminal and the BSM for managing subscriber information ofthe terminal, and upon receiving the first request message, transmittinga first request response message including the RKM to the BSD/A.

In an exemplary embodiment, the BSD/A transmits to the BSM a secondrequest message requesting delivery of a Long-Term Key Message (LKM)provided to the terminal during subscription of a broadcast service andincluding at least one service or content's identifier, and uponreceiving the LKM from the BSM, transmits the LKM to the terminal andupon receiving the second request message, the BSM transmits a secondrequest response message including the LKM to the BSD/A.

In an exemplary embodiment, the BSD/A transmits to the BSM a thirdrequest message requesting delivery of a Short-Term Key Message (SKM)including a Traffic Encryption Key (TEK) used for decryption of thebroadcast service by the terminal and including at least one service orcontent's identifier, and upon receiving the SKM from the BSM, transmitsthe SKM to the terminal and upon receiving the third request message,the BSM transmits a third request response message including the SKM tothe BSD/A.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other objects, features and advantages of the presentinvention will become more apparent from the following detaileddescription when taken in conjunction with the accompanying drawings inwhich:

FIG. 1 is a signaling diagram illustrating a signal flow of encryptioninformation in a mobile broadcast system according to an exemplaryembodiment of the present invention;

FIGS. 2A and 2B are diagrams illustrating an information flow betweenentities of a server according to an exemplary embodiment of the presentinvention, for Service Protection and Content Protection, respectively;

FIGS. 3A and 3B are diagrams illustrating an interfacing method betweena BSA and a BSM for Content Protection according to an exemplaryembodiment of the present invention;

FIG. 4 is a diagram illustrating a protocol stack constituting aninterface between a BSA and a BSM according to an exemplary embodimentof the present invention;

FIGS. 5A and 5B are diagrams illustrating a method for acquiring TEK bya BSD/A for Service Protection according to an exemplary embodiment ofthe present invention;

FIG. 6 is a diagram illustrating a protocol stack for an interfacebetween a BSD/A and a BSM for Service Protection according to anexemplary embodiment of the present invention;

FIGS. 7A and 7B are diagrams illustrating a method for acquiring SKM bya BSD/A according to an exemplary embodiment of the present invention;

FIGS. 8A and 8B are diagrams illustrating a method for acquiring LKM bya BSD/A according to an exemplary embodiment of the present invention;

FIGS. 9A and 9B are diagrams illustrating a method for acquiring RKM bya BSD/A for Service Protection and Content Protection according to anexemplary embodiment of the present invention;

FIG. 10 is a diagram illustrating a protocol stack for an interfacebetween a BSD/A and a BSM for Service Protection according to anexemplary embodiment of the present invention;

FIG. 11 is a diagram illustrating a protocol stack for an interfacebetween a BSD/A and a BSM for Content Protection according to anexemplary embodiment of the present invention; and

FIG. 12 is a diagram illustrating a Terminal in a mobile broadcastsystem according to an exemplary embodiment of the present invention.

Throughout the drawings, the same drawing reference numerals will beunderstood to refer to the same elements, features, and structures.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

The matters defined in the description such as a detailed constructionand elements are provided to assist in a comprehensive understanding ofthe embodiments of the invention and are merely exemplary. Accordingly,those of ordinary skill in the art will recognize that various changesand modifications of the embodiments described herein can be madewithout departing from the scope and spirit of the invention. Also,descriptions of well-known functions and constructions are omitted forclarity and conciseness. Exemplary embodiments of the present inventionwill now be described in detail with reference to the drawings.

In the following detailed description, exemplary embodiments of thepresent invention for achieving the above and other objects will bepresented. Although names of the entities defined in 3rd GenerationPartnership Project (3GPP) which is the asynchronous mobilecommunication standard, or Open Mobile Alliance (OMA) which is theterminal application standard, will be used for convenience, thestandards and names should not limit the scope of the present invention,and the present invention can be applied to the systems having a similartechnical background.

The present invention proposes a method and system for protecting abroadcast service. Specifically, the present invention proposes astructure for service protection and a function of each entity in thebroadcast network. To this end, the present invention stably delivers aservice broadcasted to a terminal according to structure and function ofeach entity, including the terminal, thereby allowing the terminal toreproduce the service.

An exemplary mobile broadcast system and a message flow therein will nowbe described in detail with reference to FIG. 1.

FIG. 1 is a signaling diagram illustrating a signal flow of encryptioninformation in a mobile broadcast system according to an exemplaryembodiment of the present invention.

A function of each entity in FIG. 1 will first be described. A ContentCreation (CC) 10 is a provider of Broadcast Service (BCAST) service. TheBCAST service can include audio/video broadcast service, music/data filedownload service, and the like.

A BCAST Service Application (BSA) 20 processes data of the BCAST serviceprovided from the Content Creation 10 in a form appropriate for theBCAST network, generates BCAST service data, and generates standardizedmetadata necessary for mobile broadcast guide.

A BCAST Service Distribution/Adaptation (BSD/A) 30 establishes a carrierover which it will transmit the BCAST service data provided from the BSA20, determines a delivery schedule of the BCAST service, and generates amobile broadcast guide.

A BCAST Subscription Management (BSM) 40 manages subscriptioninformation and service provisioning information for reception of theBCAST service, and information on an apparatus for receiving the BCASTservice.

A Terminal 50 is a terminal capable of receiving the BCAST service, andcan be connected to a cellular network according to terminal capability.It will be assumed herein that the Terminal 50 is a terminal that can beconnected to the cellular network.

A description will now be made of Content Protection and ServiceProtection according to an exemplary embodiment of the presentinvention. The Content Protection protects the broadcasted files andstreams. Rights Management for contents is performed by a terminal. Theprotected contents are encrypted by the BSA 20 and then broadcast to aTerminal 50. The Service Protection protects the broadcasted files andstreams, and encryption on the contents is performed by the BSD/A 30.The Content Protection is similar to the Service Protection in terms ofprotecting the contents. However, unlike the Service Protection, theContent Protection differs according to use/nonuse of DRM. That is, theContent Protection includes a function of managing a valid interval ofthe contents that the terminal has received, and possibility of copyingthe contents. For the Content Protection, the contents are encrypted bythe BSA 20 and then broadcast to a Terminal 50.

For both the Service Protection and the Content Protection, the BSM 40performs subscription management on the terminal. As the broadcastservice is delivered to the Terminal 50 through the entities for eachfunction, a user of Terminal 50 can enjoy the service. Herein, a messagerelated to the Service Protection and the Content Protection will becalled ‘encryption information’.

An exemplary method for delivering an encryption information messagewill now be described with reference to FIG. 1. In order to use thebroadcasted service and contents, a Terminal 50 should register in theBSM 40 and then receive a Registration Key Material (RKM) in step 100.Thereafter, if the Terminal 50 subscribes to a particular broadcastservice, it should acquire a Long-Term Key Message (LKM) in step 110. Inaddition, the Terminal 50 should acquire a Short-Term Key Message (SKM)used for actually decrypting the encrypted service and contents in step120. The Terminal 50 can decrypt the LKM using the RKM, and can decryptthe SKM using a Service Encryption Key (SEK) obtained as a result of thedecryption. The SKM includes a Traffic Encryption Key (TEK), and theTerminal 50 can actually decrypt the encrypted service and contentsusing the TEK. It is shown in FIG. 1 that the encryption informationmessages such as RKM, LKM and SKM are delivered from the BSD/A 30 to theTerminal 50 over a broadcast channel. A Terminal 50 capable of using aninteraction channel, although not shown in FIG. 1, can alternativelyreceive the RKM and the LKM through direct communication with the BSM40.

A description will now be made of elements of exemplary messages usedfor delivery of encryption information.

Table 1 to Table 6 below show schema tables of the messages describedabove, and show in regular sequence definitions of the message formatsused in exemplary embodiments of the present invention, and adescription of each field is specified in the tables. TABLE 1 RequestMessage Format Req-1 Cate- Cardi- Data Name Type gory nality DescriptionType Tag E M 1 Type of message Integer Version E O 1 Version of standardInteger supported by this message Message ID E M 1 ID of this messageString Destination E M 1 Message destination String ID Source E M 1Message source ID String Service/ E M 1 Associated infor- String Contentmation such as Info. Service/content ID Time E O 1 Message-deliveredString Time

TABLE 2 Response Message Format Res-1 Name Type Category CardinalityDescription Data Type Tag E M 1 Type of message Integer Version E O 1Version of standard supported by this message Integer Message ID E M 1ID of request message String Destination E M 1 Message destination IDString Source E M 1 Message source ID String Service/Content E O 1Associated information such as Service/content String Info. ID Status EM 1 Response result of message Integer Data E O 1 Information intendedto be delivered to Binary destination Time E O 1 Message-delivered timeString

TABLE 3 Response Message Format Res-2 Name Type Category CardinalityDescription Data Type Tag E M 1 Type of message Integer Message ID E M 1ID of request message String Status E M 1 Response result of messageInteger Data E O 1 Information intended to be delivered to Binarydestination

TABLE 4 Delivery Message Format Tra-1 Name Type Category CardinalityDescription Data Type Tag E M 1 Type of message Integer Version E O 1Version of standard supported by this message Integer Target E M 1Target terminal of this message String Terminal Message ID E M 1 ID ofthis message String Destination E M 1 Message destination ID StringSource E M 1 Message source ID String Service/Content E M 1 Associatedinformation such as Service/content String Info. ID Data E M 1Information intended to be delivered to Binary destination Time E O 1Message-delivered time String

TABLE 5 Confirm Message Format Con-1 Name Type Category CardinalityDescription Data Type Tag E M 1 Type of message Integer Version E O 1Version of standard supported by this message Integer Message ID E M 1ID of delivery message String Destination E M 1 Message destination IDString Source E M 1 Message source ID String Service/Content E O 1Associated information such as Service/content String Info. ID Status EM 1 Confirmation result of message Integer Time E O 1 Message-deliveredtime String

TABLE 6 Confirm Message Format Con-2 Name Type Category CardinalityDescription Data Type Tag E M 1 Type of message Integer Message ID E M 1ID of delivery message String Status E M 1 Confirmation result ofmessage Integer

In the tables, ‘Name’ indicates names of elements and attributesconstituting the corresponding message. ‘Type’ indicates whether thecorresponding name corresponds to the type of an element or anattribute. Each element has values of E1, E2, E3 and E4. E1 means anupper element for the whole message, E2 indicates a sub-element of E1,E3 indicates a sub-element of E2, and E4 indicates a sub-element of E3.The attribute is indicated by A, and A indicates an attribute of thecorresponding element. For example, A under E1 indicates an attribute ofE1. ‘Category’ is used for indicating whether a corresponding element orattribute is mandatory, and has a value M if the value is mandatory, anda value O if the value is optional. ‘Cardinality’ indicates relationsbetween the elements, and has values of {0, 0 . . . 1, 1, 0 . . . n, 1 .. . n}, where “0” means an optional relation, “1” means a mandatoryrelation, and ‘n’ means the possibility of having a plurality of values.For example, ‘0 . . . n’ means the possibility that there is nocorresponding element or there are n corresponding elements.‘Description’ defines the meaning of the corresponding element orattribute. ‘Data Type’ indicates a data type of the correspondingelement or attribute.

In Table 7 below, the type of each message is distinguished using Tagused in the message formats defined in Table 1 to Table 6. However, theTag values defined herein simply distinguish the message types, and arenot always fixed, but subject to change according to circumstances.

In the Response Message and the Confirm Message, Status=‘0’ indicatesthat the Request and Delivery Messages were successfully received andthe associated item was formed, and Status=‘1’ indicates that receptionof the Request and Delivery Messages was failed and execution of theassociated item was failed.

Each message can obtain improvement in performance using Res-2 or Con-2,which is a shortened message provided using Message ID as shown in‘Applied Message Format’ of Table 7 below. TABLE 7 Message Type andApplied Message Format Based on Tag Applied Message Delivery Tag MessageType Format Info. 1 TEK Request Message Req-1 TEK 2 TEK Request ResponseMessage Res-1 or Res-2 3 TEK Delivery Message Tra-1 4 TEK DeliveryConfirm Message Con-1 or Con-2 5 SKM Request Message Req-1 SKM 6 SKMRequest Response Message Res-1 or Res-2 7 SKM Delivery Message Tra-1 8SKM Delivery Confirm Message Con-1 or Con-2 9 LKM Request Message Req-1LKM 10 LKM Request Response Message Res-1 or Res-2 11 LKM DeliveryMessage Tra-1 12 LKM Delivery Confirm Message Con-1 or Con-2 13 RKMRequest Message Req-1 RKM 14 RKM Request Response Message Res-1 or Res-215 RKM Delivery Message Tra-1 16 RKM Delivery Confirm Message Con-1 orCon-2

Exemplary embodiments of the present invention provide a method forexchanging encryption information such as TEK, SKM, LKM and RKM relatedto the Service Protection and Content Protection between the BSA 20 andthe BSM 40, and between the BSD/A 30 and the BSM 40. FIGS. 2A and 2Bshow the information exchanged between entities, and the detailedexamples will be described with reference to the accompanying drawings.

FIGS. 2A and 2B are diagrams illustrating an information flow betweenentities of a server according to an exemplary embodiment of the presentinvention, for Service Protection and Content Protection, respectively.Referring to FIGS. 2A and 2B, an entity for performing the ServiceProtection includes a Service Protection-Encryption (SP-E) 31 and aService Protection-Key Distribution (SP-KD) 32 in the BSD/A 30. The SP-E31 serves to encrypt the service, and the SP-KD 32 serves to transmitthe associated encryption key information up to a Terminal 50 over abroadcast channel. The BSM 40, including a Service Protection-Management(SP-M) 41 therein, manages subscription of the terminal and generationof the encryption key.

For the Content Protection, a File Distribution (FD) 33 in the BSD/A 30receives the encryption key information delivered from the BSM 40 anddelivers the received encryption key information to a terminal over abroadcast channel. The BSM 40, including a Content Protection-Management(CP-M) 42 therein, manages subscription of the terminal and generationof the encryption key. The BSA 20, including a ContentProtection-Encryption (CP-E) 21 therein, manages encryption of thecontents.

FIGS. 3A and 3B are diagrams illustrating an interfacing method betweena BSA 20 and a BSM 40 for Content Protection according to an exemplaryembodiment of the present invention, and the information transmitted forthe Content Protection will be described. In an exemplary ContentProtection method, because encryption is performed in the BSA 20, theencryption key generated by the BSM 40 is delivered to the BSA 20.Because the key used for encrypting the contents in the mobile broadcastsystem is TEK, the TEK generated by the BSM 40 should be delivered tothe BSA 20.

As shown in FIG. 3A, an exemplary delivery method starts with a TEKRequest Message transmitted from the BSA 20 in step 300, and Tagindicating the TEK Request Message is set to ‘1’. A Destination fieldindicates the BSM 40 and a Source field indicates the BSA 20. Uponreceipt of the TEK Request Message, the CP-M 42 in the BSM 40 transmitsa TEK Request Response Message with Tag=‘2’ in step 310. If a Statusfield of the Response is set to ‘0’, TEK is stored in a Data fieldbefore being transmitted, and if the TEK is not transmitted, the Statusfield is set to ‘1’ before being transmitted.

In the method of FIG. 3B, the BSM 40 transmits TEK without a requestfrom the BSA 20. In an exemplary embodiment, the CP-M 42 in the BSM 40transmits a TEK Delivery Message with Tag=‘3’ having TEK included in aData field to the CP-E 21 in the BSA 20 in step 320. In response, theBSA 20 transmits a TEK Delivery Confirm Message with Tag=‘4’ to the BSM40 in step 330. In an exemplary embodiment, a Status field is set to ‘0’indicating normal receipt of TEK. If reception of the TEK is failed, theStatus field is set to ‘1’.

FIG. 4 illustrates a protocol stack constituting an interface between aBSA 20 and a BSM 40 according to an exemplary embodiment of the presentinvention. Referring to FIG. 4, the BSA 20 and the BSM 40 can exchangedata by achieving compatibility with each other using a protocol. Datadelivery protection between the BSA 20 and the BSM 40 can realize dataprotection without restriction of protocol and data of an upper layerusing IPSec. TCP protocol and HTTP/HTTPS exist as an IPSec upper layer,and the CP-E 21 in the BSA 20 and the CP-M 42 in the BSM 40 existthereon for message exchange and an associated operation for theinterface.

FIGS. 5A and 5B illustrate a TEK acquisition method in which a BSD/A 30encrypts and broadcasts a service for Service Protection according to anexemplary embodiment of the present invention.

Referring to FIG. 5A, the SP-E 31 in the BSD/A 30 transmits a TEKRequest Message to the BSM 40 in step 400. The TEK Request Message has aTag value ‘1’, and its Destination and Source indicate the BSM 40 andthe BSD/A 30, respectively. In response to the TEK Request Message, theBSM 40 transmits a TEK Request Response Message with Tag=‘2’ in step410. The BSM 40 sets a Status value to ‘0’ when it transmits therequested TEK. Otherwise, the BSM 40 sets the Status value to ‘1’. Whenthe Status value is set to ‘0’, TEK is stored in a Data field of the TEKRequest Response Message.

In an exemplary embodiment shown in FIG. 5B, the BSM 40 directlytransmits TEK without a request from the BSD/A 30. Referring to FIG. 5B,the SP-M 41 in the BSM 40 transmits a TEK Delivery Message with Tag=‘3’having TEK included therein to the BSD/A 30 in step 420. In response,the BSD/A 30 transmits a TEK Delivery Confirm Message with Tag=‘4’ tothe BSM 40 in step 430. If the BSD/A 30 has succeeded in receiving theTEK, it sets a Status value of the TEK Delivery Confirm Message to ‘0’.However, if the BSD/A 30 has failed in receiving the TEK, it sets theStatus value ‘1’.

FIG. 6 is a diagram illustrating a protocol stack for an interfacebetween a BSD/A 30 and a BSM 40 for Service Protection according to anexemplary embodiment of the present invention. Safety between interfacesis protected using IPSec, and a protocol related to a service protectionmethod is transmitted through TCP and HTTP/HTTPS. Encryption informationtransmitted from the BSM 40 is managed by the BSD/A 30, and theencryption information includes RKM, LKM, SKM and TEK.

FIGS. 7A and 7B are diagrams illustrating a method for acquiring SKM bythe BSD/A 30 according to an exemplary embodiment of the presentinvention. This exemplary method can be applied for Service and/orContent Protection. The SKM is an encryption key with which a terminalcan decrypt the service or contents encrypted by the BSD/A 30. The SKMcan be delivered from the BSM 40 to a Terminal 50 over an interactionchannel. However, in the broadcast channel environment, the SKM shouldbe delivered from the BSD/A 30 to a Terminal 50 over a broadcastchannel.

Referring to FIG. 7A, the BSD/A 30 transmits an SKM Request Message tothe BSM 40 in step 500. In the BSM 40, an entity for processing themessage can be the SP-M 41 for Service Protection and/or the CP-M 42 forContent Protection. The SKM Request Message has a Tag value ‘5’, and itsDestination and Source indicate the BSM 40 and the BSD/A 30,respectively. In response to the SKM Request Message, the BSM 40transmits an SKM Request Response Message with Tag=‘6’in step 510. Whenthe BSM 40 transmits the requested SKM, it sets a Status value to ‘0’and a Data field to SKM. Otherwise, when the BSM 40 cannot transmit theSKM, it sets the Status value to ‘1’.

In an exemplary embodiment shown in FIG. 7B, the BSM 40 directlytransmits SKM without a request from the BSD/A 30. The BSM 40 transmitsan SKM Delivery Message with Tag=‘7’ having SKM included therein to theBSD/A 30 in step 520. In response, the BSD/A 30 transmits an SKMDelivery Confirm Message with Tag=‘8’ to the BSM 40 in step 530. If theBSD/A 30 has succeeded in receiving the SKM, it sets a Status value ofthe SKM Delivery Confirm Message to ‘0’. However, if the BSD/A 30 hasfailed in receiving the SKM, it sets the Status value ‘1’.

For Service Protection, this process is managed by the SP-KD 32 in theBSD/A 30 and the SP-M 41 in the BSM 40. For Content Protection, thisprocess is managed by the FD 33 in the BSD/A 30 and the CP-M 42 in theBSM 40.

FIGS. 8A and 8B are diagrams illustrating a method for acquiring LKM bya BSD/A 30 according to an exemplary embodiment of the presentinvention. In the service/content protection method, LKM information isexchanged using a broadcast channel. The LKM can be delivered from theBSM 40 to the Terminal 50 over an interaction channel. However, in thebroadcast channel environment, the LKM should be delivered from theBSD/A 30 to a Terminal 50 over the broadcast channel.

Referring to FIG. 8A, the BSD/A 30 transmits an LKM Request Message tothe BSM 40 in step 600. The LKM Request Message has a Tag value ‘9’, andits Destination and Source indicate the BSM 40 and the BSD/A 30,respectively. In response to the LKM Request Message, the BSM 40transmits an LKM Request Response Message with Tag=‘10’ in step 610.When the BSM 40 intends to transmit the requested LKM, it sets a Statusvalue to ‘0’. Otherwise, the BSM 40 sets the Status value to ‘1’. Whenthe Status value is set to ‘0’, LKM is stored in a Data field. When theStatus value is set to ‘1’, the LKM Request Response Message istransmitted without the Data field.

In the case of FIG. 8B, the BSM 40 directly transmits LKM without aresponse from the BSD/A 30. In this case, the BSM 40 transmits an LKMDelivery Message with Tag=‘11’ having LKM included therein to the BSD/A30 in step 620. In response, the BSD/A 30 transmits an LKM DeliveryConfirm Message with Tag=‘12’ to the BSM 40 in step 630. If the BSD/A 30has succeeded in receiving the LKM, it sets a Status value of the LKMDelivery Confirm Message to ‘0’. However, if the BSD/A 30 has failed inreceiving the LKM, it sets the Status value to ‘1’.

For Service Protection, this process is managed by the SP-KD 32 in theBSD/A 30 and the SP-M 41 in the BSM 40. For Content Protection, thisprocess is managed by the FD 33 in the BSD/A 30 and the CP-M 42 in theBSM 40.

FIGS. 9A and 9B are diagrams illustrating a method for acquiring RKM bya BSD/A 30 for Service Protection and Content Protection according to anexemplary embodiment of the present invention.

RKM can be delivered from the BSM 40 to the Terminal 50 over aninteraction channel. However, in the broadcast channel environment, theRKM should be delivered from the BSM 40 to the Terminal 50 over thebroadcast channel.

Referring to FIG. 9A, the BSD/A 30 transmits an RKM Request Message tothe BSM 40 in step 700. The RKM Request Message has a Tag value ‘13, andits Destination and Source indicate the BSM 40 and the BSD/A 30,respectively. In response to the RKM Request Message, the BSM 40transmits an RKM Request Response Message with Tag=‘14’ to the BSD/A 30in step 710. When the BSM 40 intends to transmit the requested RKM, itsets a Status value to ‘0’. Otherwise, the BSM 40 sets the Status valueto ‘1’. If the Status value is set to ‘0’, RKM is stored in a Data fieldbefore being transmitted. However, if the Status value is set to ‘1’,the RKM Request Response Message is transmitted without the Data field.

In the case of FIG. 9B, the BSM 40 directly transmits RKM without arequest from the BSD/A 30. In an exemplary embodiment, the BSM 40transmits an RKM Delivery Message with Tag=‘15’ having RKM includedtherein to the BSD/A 30 in step 720. In response, the BSD/A 30 transmitsan RKM Delivery Confirm Message with Tag=‘16’ to the BSM 40 in step 730.If the BSD/A 30 has succeeded in receiving the RKM, it sets a Statusvalue of the RKM Delivery Confirm Message to ‘0’. However, if the BSD/A30 has failed in receiving the RKM, it sets the Status value to ‘1’.

For Service Protection, this process is managed by the SP-KD 32 in theBSD/A 30 and the SP-M 41 in the BSM 40. For Content Protection, thisprocess is managed by the FD 33 in the BSD/A 30 and the CP-M 42 in theBSM 40.

FIG. 10 illustrates a protocol stack for an interface between a BSD/A 30and a BSM 40 for Service Protection according to an exemplary embodimentof the present invention. Safety between interfaces is protected usingIPSec, and a protocol related to a service protection method istransmitted through TCP and HTTP/HTTPS. Associated encryptioninformation includes TEK, SKM, LKM and RKM.

FIG. 11 illustrates a protocol stack for an interface between a BSD/A 30and a BSM 40 for Content Protection according to an exemplary embodimentof the present invention. Safety between interfaces is protected usingIPSec, and a protocol related to a content protection method istransmitted through TCP and HTTP/HTTPS. Associated encryptioninformation includes SKM, LKM and RKM.

With reference to FIG. 12, a description will now be made of a Terminal50 according to an exemplary embodiment of the present invention.

As illustrated in FIG. 12, a Terminal 50 according to an exemplaryembodiment of the present invention comprises an Application module1200, a DRM module 1210, an Authentication module 1235, a Secure Storagemodule 1260, a Communication module 1265, and a User Identity ModuleInterface (UIM I/F) module 1270.

Specifically, the Application module 1200, which may be a module likeMedia Player™, serves to reproduce decrypted contents provided from theDRM module 1210, and the DRM module 1210 serves to manage registration,service subscription, and content use.

The DRM module 1210 may include a DRM Management module 1213, aRegistration module 1215, a Rights Management module 1220, a Key StreamManagement module 1225, and a Content Decryption module 1230. Of themodules, the Registration module 1215 performs a registration operation,and the Rights Management module 1220 manages analysis and use of theRights information acquired during service subscription. The Key StreamManagement module 1225 performs an operation of decrypting the encryptedtraffic key with a service key, and the Content Decryption module 1230performs an operation of decrypting the encrypted contents with atraffic key. The entire operation of the DRM-related modules isperformed under the control of the DRM Management module 1213.

The Authentication module 1235 manages authentication protocol executionwith a user identification module and a network, for example, a serviceprovider, and performs message generation and verification using itslower module. The Authentication module 1235 may include anAuthentication Manager 1240 for taking charge of the overall protocolexecution and managing an authentication fiction, an EncryptionDecryption module 1245 for performing an encryption/decryption operationwith its lower module, a Digital Signature module 1250 for managingelectronic signature, and a MAC module 1255 for performing a MACoperation.

Specifically, the DRM module 1210 and the Authentication module 1235acquire a group key by verifying the Registration Response Messagereceived from the BSM 40 according to an exemplary embodiment of thepresent invention, and acquire Rights information from the ServiceSubscription Response Message received from the BSM 40 using the groupkey. In addition, upon receipt of a Traffic Key Message from the BSD/A30, the DRM module 1210 and the Authentication module 1235 acquire atraffic key using the Rights information, and decrypt the encryptedservice transmitted from the BSD/A 30 using the acquired traffic key.

The Communication module 1265, in charge of communication with anetwork, receives a message from the network and transmits a responsemessage associated in response to the received message. Specifically,the Communication module 1265 receives a message from the BSD/A 30 overa broadcast channel according to an embodiment of the present invention.According to another exemplary embodiment of the present invention, theCommunication module 1265 exchanges messages with the BSM 40 over aninteraction channel, and receives the Traffic Key Message and theencrypted service from the BSD/A 30.

The Secure Storage module 1260 stores encryption keys, and the UIM I/Fmodule 1270 takes charge of communication -with a User Identity Module(UIM) (not shown).

As can be understood from the foregoing description, the presentinvention provides interfaces for transmitting encryption informationbetween entities, thereby providing reliable Service/Content Protectionfor broadcast service.

While the invention has been shown and described with reference toexemplary embodiments thereof, it will be understood by those skilled inthe art that various changes in form and details may be made thereinwithout departing from the spirit and scope of the invention as definedby the appended claims.

1. A method for transmitting/receiving encryption information in amobile broadcast system supporting broadcast service (BCAST), the methodcomprising: transmitting, by a broadcast service (BCAST) ServiceDistribution/Adaptation (BSD/A) to a BCAST Subscription Management (BSM)provided for managing subscriber information of a terminal, a firstrequest message including at least one of a service identifier and acontent identifier and requesting delivery of a Registration KeyMaterial (RKM) for registration of the broadcast service of theterminal; and transmitting, by the BSM, a first request response messageincluding the RKM to the BSD/A upon receiving the first request message.2. The method of claim 1, further comprising: transmitting, by the BSD/Ato the BSM, a second request message including the at least one of theservice identifier and the content identifier and requesting delivery ofa Long-Term Key Message (LKM) provided to the terminal duringsubscription of a broadcast service; and transmitting, by the BSM, asecond request response message including the LKM to the BSD/A uponreceiving the second request message.
 3. The method of claim 2, furthercomprising: transmitting, by the BSD/A to the BSM, a third requestmessage including the at least one of the service identifier and contentidentifier and requesting delivery of a Short-Term Key Message (SKM)including a Traffic Encryption Key (TEK) used for decryption of thebroadcast service by the terminal; and transmitting, by the BSM, a thirdrequest response message including the SKM to the BSD/A upon receivingthe third request message.
 4. The method of claim 3, wherein each of thefirst to third request messages comprises fields defined in thefollowing table: Name Type Category Cardinality Description Data TypeTag E M 1 Type of message Integer Version E O 1 Version of standardsupported by this message Integer Message ID E M 1 ID of this messageString Destination E M 1 Message destination ID String Source E M 1Message source ID String Service/Content E M 1 Associated informationsuch as Service/content String Info. ID Time E O 1 Message-deliveredTime String


5. The method of claim 3, wherein each of the first to third requestresponse messages comprises fields defined in the following table: NameType Category Cardinality Description Data Type Tag E M 1 Type ofmessage Integer Version E O 1 Version of standard supported by thismessage Integer Message ID E M 1 ID of request message StringDestination E M 1 Message destination ID String Source E M 1 Messagesource ID String Service/Content E O 1 Associated information such asService/content String Info. ID Status E M 1 Response result of messageInteger Data E O 1 Information intended to be delivered to Binarydestination Time E O 1 Message-delivered time String


6. A method for transmitting/receiving encryption information in amobile broadcast system supporting broadcast service (BCAST), the methodcomprising: transmitting, by a BCAST Subscription Management (BSM) to aBCAST Service Distribution/Adaptation (BSD/A), a first delivery messagecomprising at least one of a service identifier and a content identifierand including a Registration Key Material (RKM) for registration of asubscriber of a terminal; and transmitting, by the BSD/A to the BSM, afirst delivery confirmation message including information indicatingsuccess/failure in receipt of the first delivery message.
 7. The methodof claim 6, further comprising: transmitting, by the BSM to the BSD/A, asecond delivery message including the at least one of the serviceidentifier and content identifier and including a Long-Term Key Message(LKM) provided to the terminal during subscription of a broadcastservice; and transmitting, by the BSD/A to the BSM, a second deliveryconfirmation message including information indicating success/failure inreceipt of the second delivery message.
 8. The method of claim 7,further comprising: transmitting, by the BSM to the BSD/A, a thirddelivery message including the at least one of the service identifierand the content identifier and including a Short-Term Key Message (SKM)including a Traffic Encryption Key (TEK) used for decryption of thebroadcast service by the terminal; and transmitting, by the BSD/A to theBSM, a third delivery confirmation message including informationindicating success/failure in receipt of the third delivery message. 9.The method of claim 8, wherein each of the first to third deliverymessages comprises fields defined in the following table: Name TypeCategory Cardinality Description Data Type Tag E M 1 Type of messageInteger Version E O 1 Version of standard supported by this messageInteger Target E M 1 Target terminal of this message String TerminalMessage ID E M 1 ID of this message String Destination E M 1 Messagedestination ID String Source E M 1 Message source ID StringService/Content E M 1 Associated information such as Service/contentString Info. ID Data E M 1 Information intended to be delivered toBinary destination Time E O 1 Message-delivered time String


10. The method of claim 8, wherein each of the first to third deliveryconfirmation messages comprises fields defined in the following table:Name Type Category Cardinality Description Data Type Tag E M 1 Type ofmessage Integer Version E O 1 Version of standard supported by thismessage Integer Message ID E M 1 ID of delivery message StringDestination E M 1 Message destination ID String Source E M 1 Messagesource ID String Service/Content E O 1 Associated information such asService/content String Info. ID Status E M 1 Confirmation result ofmessage Integer Time E O 1 Message-delivered time String


11. A mobile broadcast system supporting broadcast service (BCAST),comprising: a BCAST Subscription Management (BSM) for managingsubscriber information of a terminal, and for transmitting to a BCASTService Distribution/Adaptation (BSD/A) a first delivery messageincluding a Registration Key Material (RKM) provided for registration ofthe broadcast service of the terminal of the terminal and including atleast one of a service identifier and a content identifier; and theBSD/A for transmitting to the BSM a first delivery confirmation messageincluding information indicating success/failure in receipt of the firstdelivery message, and transmitting the RKM to the terminal.
 12. Themobile broadcast system of claim 11, wherein the BSM transmits to theBSD/A a second delivery message including a Long-Term Key Message (LKM)provided to the terminal during subscription of a broadcast service andalso including the at least one of the service identifier and thecontent identifier; and wherein the BSD/A transmits to the BSM a seconddelivery confirmation message including information indicatingsuccess/fail in receipt of the second delivery message, and transmitsthe LKM to the terminal.
 13. The mobile broadcast system of claim 12,wherein the BSM transmits to the BSD/A a third delivery messageincluding a Short-Term Key Message (SKM) including a Traffic EncryptionKey (TEK) used for decryption of the broadcast service by the terminaland also including the at least one of the service identifier and thecontent identifier; and wherein the BSD/A transmits to the BSM a thirddelivery confirmation message including information indicatingsuccess/failure in receipt of the third delivery message, and transmitsthe SKM to the terminal.
 14. The mobile broadcast system of claim 13,wherein each of the first to third delivery messages comprises fieldsdefined in the following table: Name Type Category CardinalityDescription Data Type Tag E M 1 Type of message Integer Version E O 1Version of standard supported by this message Integer Target E M 1Target terminal of this message String Terminal Message ID E M 1 ID ofthis message String Destination E M 1 Message destination ID StringSource E M 1 Message source ID String Service/Content E M 1 Associatedinformation such as Service/content String Info. ID Data E M 1Information intended to be delivered to Binary destination Time E O 1Message-delivered time String


15. The mobile broadcast system of claim 13, wherein each of the firstto third delivery confirmation messages comprises fields defined in thefollowing table: Name Type Category Cardinality Description Data TypeTag E M 1 Type of message Integer Version E O 1 Version of standardsupported by this message Integer Message ID E M 1 ID of deliverymessage String Destination E M 1 Message destination ID String Source EM 1 Message source ID String Service/Content E O 1 Associatedinformation such as Service/content String Info. ID Status E M 1Confirmation result of message Integer Time E O 1 Message-delivered timeString


16. A mobile broadcast system supporting broadcast service (BCAST),comprising: a BCAST Service Distribution/Adaptation (BSD/A) fortransmitting to a BCAST Subscription Management (BSM) a first requestmessage requesting delivery of a Registration Key Material (RKM) forregistration of the broadcast service of the terminal and including atleast one of a service identifier and a content identifier, and uponreceiving the RKM from the BSM, transmitting the RKM to the terminal;and the BSM for managing subscriber information of the terminal, andupon receiving the first request message, transmitting a first requestresponse message including the RKM to the BSD/A.
 17. The mobilebroadcast system of claim 16, wherein the BSD/A transmits to the BSM asecond request message requesting delivery of a Long-Term Key Message(LKM) provided to the terminal during subscription of a broadcastservice and including the at least one of the service identifier and thecontent identifier, and upon receiving the LKM from the BSM, transmitsthe LKM to the terminal; and wherein upon receiving the second requestmessage, the BSM transmits a second request response message includingthe LKM to the BSD/A.
 18. The mobile broadcast system of claim 17,wherein the BSD/A transmits to the BSM a third request messagerequesting delivery of a Short-Term Key Message (SKM) including aTraffic Encryption Key (TEK) used for decryption of the broadcastservice by the terminal and including the at least one of the serviceidentifier and the content identifier, and upon receiving the SKM fromthe BSM, transmits the SKM to the terminal; and wherein upon receivingthe third request message, the BSM transmits a third request responsemessage including the SKM to the BSD/A.
 19. The mobile broadcast systemof claim 17, wherein each of the first to third request messagescomprises fields defined in the following table: Name Type CategoryCardinality Description Data Type Tag E M 1 Type of message IntegerVersion E O 1 Version of standard supported by this message IntegerMessage ID E M 1 ID of this message String Destination E M 1 Messagedestination ID String Source E M 1 Message source ID StringService/Content E M 1 Associated information such as Service/contentString Info. ID Time E O 1 Message-delivered Time String


20. The mobile broadcast system of claim 17, wherein each of the firstto third request response messages comprises fields defined in thefollowing table: Name Type Category Cardinality Description Data TypeTag E M 1 Type of message Integer Version E O 1 Version of standardsupported by this message Integer Message ID E M 1 ID of request messageString Destination E M 1 Message destination ID String Source E M 1Message source ID String Service/Content E O 1 Associated informationsuch as Service/content String Info. ID Status E M 1 Response result ofmessage Integer Data E O 1 Information intended to be delivered toBinary destination Time E O 1 Message-delivered time String


21. A method for transmitting/receiving encryption information in amobile broadcast system supporting broadcast service (BCAST), the methodcomprising: transmitting, by a broadcast service (BCAST) ServiceDistribution/Adaptation (BSD/A) to a BCAST Subscription Management (BSM)provided for managing subscriber information of a terminal, a firstrequest message including at least one of a service identifier and acontent identifier and requesting delivery of a Registration KeyMaterial (RKM) for registration of the broadcast service of theterminal; transmitting, by the BSM, a first request response messageincluding the RKM to the BSD/A upon receiving the first request message;transmitting, by the BSD/A to the BSM, a second request messageincluding the at least one of the service identifier and the contentidentifier and requesting delivery of a Long-Term Key Message (LKM)provided to the terminal during subscription of a broadcast service;transmitting, by the BSM, a second request response message includingthe LKM to the BSD/A upon receiving the second request message;transmitting, by the BSD/A to the BSM, a third request message includingthe at least one of the service identifier and content identifier andrequesting delivery of a Short-Term Key Message (SKM) including aTraffic Encryption Key (TEK) used for decryption of the broadcastservice by the terminal; transmitting, by the BSM, a third requestresponse message including the SKM to the BSD/A upon receiving the thirdrequest message; and extracting, by the terminal, the TEK from the SKMusing the RKM and the LKM upon receiving the RKM, the LKM, and the SKM.